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Abstract — Systems  engineering  is  often  ineffective  in 
development  environments  where  large,  complex,  brownfield 
systems  of  systems  are  evolved  through  parallel  development  of 
new  capabilities  in  response  to  external,  time-sensitive 
requirements.  This  paper  defines  a  conceptual  framework  to 
improve  that  effectiveness  and  better  integrate  the  systems 
engineering  and  software  engineering  processes.  The 
framework  is  based  on  a  services  approach  to  systems 
engineering  and  the  use  of  kanban  techniques  to  schedule 
scarce  enterprise  systems  engineering  resources  across 
multiple  related  systems  and  software  development  projects. 
The  framework  also  addresses  the  differing  value  of  work 
items  to  multiple  stakeholders  in  the  scheduling  and 
coordination  processes.  Models  and  simulations  are  being  used 
to  capture,  refine  and  validate  the  framework  prior  to  in  vivo 
experimentation. 

Keywords — systems  engineering  process;  process  integration; 
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I .  Introduction  and  Background 

Traditional  systems  engineering  (SE)  developed  half  a 
eentury  ago,  primarily  driven  by  the  ehallenges  faeed  in  the 
aerospaee  and  defense  industries.  The  environment  was 
fairly  uniform  -  hardware-driven,  long  lived,  single  mission. 
The  result  of  this  uniformity  was  praetiees  that  worked  well 
in  that  speeifie  eontext  were  seen  as  “best  praetiees,”  and 
eame  to  define  the  diseipline  of  systems  engineering. 
Engineering  prineiples  involving  agility  and  leanness  have 
been  adopted  to  address  non-determinism  in  software 
systems.  [1]  [2]  [3].  Combining  agile-lean  software 
experienee  with  system  engineering  fundamentals  ean 
provide  praetieal,  prineiple-driven  agile-lean  systems 
engineering  approaehes  for  the  design  of  eomplex  or 
evolving  hardware-software-human  systems  [4].  This  may 
help  alleviate  the  observed  poor  performanee  of  systems 


engineering  in  meeting  sehedule  and  resouree  eonstraints  [5] 
[6]  [7]. 

This  researeh  proposes  marrying  the  ideas  of  a  serviees 
perspeetive  with  a  lean-inspired  pull  seheduling  teehnique 
sueh  as  kanban,  to  ereate  a  radieal  departure  from  the  normal 
eoneepts  of  systems  engineering.  In  an  environment  where 
there  is  an  existing  eomplex  system  eonstantly  evolving 
through  rapid-response  software  applieation  development, 
systems  engineering  is  the  glue  that  holds  all  of  the  various 
projeets  together.  It  is  eritieal  that  it  be  integrated  into  the 
various  projeets  without  unduly  delaying  them,  and  that  the 
limited  resouree  of  systems  engineering  skills  be  effieiently 
and  effeetively  deployed  so  as  not  to  unduly  delay  any 
partieular  projeet  and  still  meet  the  overall  system  priorities. 
The  serviees  approaeh  better  integrates  SE  into  the 
development  eyele,  and  the  kanban-based  seheduling 
maximizes  the  value  flow  of  the  systems  engineering  tasks 
performed.  This  projeet  has  developed  an  example  of  the 
eombined  approaeh  and  is  simulating  it  with  a  hybrid  of 
diserete  event,  eontinuous  flow,  and  agent-based  models  and 
typieal  work  streams  to  determine  if  the  idea  is  sound 
enough  to  aetually  pilot  in  an  operational  environment. 

II.  Beginning  with  Kanban 
A.  Background 

Kanban  is  a  method  assoeiated  with  lean  manufaeturing 
and  the  Toyota  Produetion  System.  A  kanban  (signal  eard) 
approaeh  provides  a  visual  means  of  managing  the  flow 
within  a  proeess.  The  signal  eards  are  ereated  to  the  agreed 
eapaeity  of  the  proeess  and  one  eard  is  assoeiated  with  eaeh 
pieee  of  work.  Here,  work  ean  mean  the  ereation  of  a  part, 
the  integration  of  a  part  into  an  assembly,  the  eompletion  of  a 
partieular  analysis  proeess,  or  whatever  bounded  and 
eompleteable  task  you  wish  to  traek  through  the  proeess. 
Onee  all  of  the  eards  have  been  assoeiated,  no  more  work  in 
that  proeess  ean  begin  until  some  pieee  of  work  is  eompleted 
and  the  eard  beeomes  available.  An  often  used  example  of  a 
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simple  kanban  is  the  use  of  a  limited  number  of  tiekets  for 
entry  into  the  Japanese  Imperial  Gardens  [8].  The 
fundamental  idea  is  to  use  visual  signals  to  synehronize  the 
flow  of  work  with  proeess  eapaeity,  limit  the  waste  of  work 
interruption,  minimize  exeess  inventory  or  delay  due  to 
shortage,  prevent  unneeessary  rework,  and  provide  a  means 
of  traeking  work  progress. 

In  knowledge  work,  the  eomponents  of  produetion  are 
ideas  and  information.  In  software  and  systems,  kanban 
systems  have  evolved  into  a  means  of  smoothing  flow  by 
balaneing  work  with  resouree  eapability.  The  eoneept  was 
extended  to  inelude  the  limiting  of  work  in  progress 
aeeording  to  eapaeity.  Work  eannot  be  started  until  there  is 
an  available  appropriate  resouree.  In  that  way,  it  is 
eharaeterized  as  a  “pull”  system,  sinee  the  work  is  pulled 
into  the  proeess  rather  than  “pushed”  via  a  sehedule. 

B.  Concept 

The  following  eoneept  was  derived  from  [8]  [9]  [10]  [11] 
[12]  [13],  workshops,  and  diseussions  with  an  industry 
working  group.  A  kanban  system  is  a  visually  monitored  set 
of  aetivities,  where  eaeh  aetivity  has  its  own  task  queue  and 
set  of  resourees  to  add  value  to  work  units  that  flow  through 
it.  The  faet  that  queues  are  ineluded  in  the  system  allows 
eosts  of  delay  and  other  usually  invisible  aspeets  of 
seheduling  to  be  front  and  eenter  in  deeision  making.  Queues 
also  provide  a  vast  body  of  experienee  and  underlying 
seienee  from  the  queuing  theory  diseipline.  Control  of  the 
kanban  system  is  generally  maintained  through  batch  sizQ, 
Work  in  Progress  (WIP)  limits  and  Classes-of-Service  (COS) 
definitions  that  prioritize  work  with  respeet  to  risk. 

The  visual  representation  of  work  is  eritieal  to  kanban 
sueeess,  beeause  it  provides  immediate  understanding  of  the 
state  of  flow  through  the  set  of  aetivities.  This  transpareney 
makes  proeess  delays  or  resouree  issues  easily  visible  and 
enables  the  team  to  reeognize  and  reaet  immediately  to 
resolve  the  eause.  Kanban  is  also  an  embodiment  of  the 
eontinuous  improvement  eoneept  (kaizen).  Flow  through  the 
kanban  system  is  measured  and  traeked  through  statistieal 
methods  that  support  tuning  the  eontrol  parameters  to 
improve  the  system.  Flow  measures  also  provide  a  good 
handle  for  effeetiveness  eomparison. 

WIP  is  partially-eompleted  work,  equivalent  to  the 
manufaeturing  eoneept  of  parts  inventory  waiting  to  be 
proeessed  by  a  produetion  step.  WIP  aeeumulates  ahead  of 
bottleneeks  unless  upstream  produetion  is  eurtailed  or  the 
bottleneek  resolved.  WIP  in  knowledge  work  ean  be  roughly 
assoeiated  to  the  number  of  tasks  that  have  been  started  and 
not  eompleted.  Limiting  WIP  is  a  eoneept  to  eontrol  flow 
and  enhanee  value  by  speeifieally  limiting  the  amount  of 
work  to  be  assigned  to  a  set  of  resourees  (a  WIP  Limit).  WIP 
limits  aeeomplish  several  goals:  they  lower  the  eontext- 
switehing  overhead  that  impaets  individuals  or  teams 
attempting  to  handle  several  simultaneous  tasks;  they 
aeeelerate  useful  value  by  eompleting  work  in  progress 
before  starting  new  work;  and,  they  provide  for  reasonable 
and  sustainable  resouree  work  loads. 

Using  small  batch  sizes  is  a  supporting  eoneept  to  WIP. 
Redueing  bateh  size  limits  rework  and  provide  flexibility  in 


seheduling  and  response  to  unforeseen  ehange.  Smaller  bateh 
sizes  help  stabilize  the  proeess  flow  and  allow  downstream 
proeesses  to  eonsume  the  batehes  smoothly,  rather  than  in  a 
start-and-stop  fashion  that  makes  ineffieient  use  of  resourees. 
The  move  from  “one  step  to  glory”  system  initiatives  to 
iterative,  deployable  inerements  is  an  example  of  redueing 
bateh  size.  Ineremental  builds  and  ongoing,  eontinuous 
integration  also  approximate  the  effeet  of  small  bateh  sizes. 

So  as  not  to  eonfuse  readers  with  the  traditional 
understanding  of  kanban  in  manufaeturing,  we  refer  to  an 
implementation  of  sueh  a  system  in  systems  or  software 
engineering  as  a  Kanban-based  Seheduling  System,  or  KSS. 

III.  Defining  an  SE  KSS  for  Rapid-Response 
Development 


A.  An  Elemental  KSS 

In  Figure  1  we  define  our  eore  building  bloek  eoneept  of 
a  KSS.  We  intend  that  this  model  be  reeursive  at  many  levels 
to  allow  for  eomplex  implementations;  this  is  shown  in 
Figure  2.  While  we  eurrently  believe  tasks  and  their 
assoeiated  parameters  eoupled  with  the  visual  representation 
of  flow  are  suffieient,  we  may  introduee  new  eoneepts  to 
enable  better  eommunieations  and  synehronization  between 
the  various  interaeting  systems.  More  about  the  speeifies  of 
the  model  ean  be  found  in  [8]  and  [19]. 


Backlog 

(Queue) 


Work  Flow 


czi 


Activity 

(WIP  Limit=6,  Resources=4) 


Completed 

Work 


CD 


I  I  Normal  Class  of  Service  Work  Item  (NCOS) 

[  )  Special  Class  of  Service  Work  Item  (SCOS) 

[  £x  ]  Expedite  Class  of  Service  Work  Item  (ECOS) 
Resource  (Individually  numbered) 
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Figure  2.  Kanban  Scheduling  System  Hierarchy 


There  is  mueh  evidenee  suggesting  a  KSS  sueh  as  this 
will  work  in  a  software  development  projeet,  but  applying  it 
to  systems  engineering,  partieularly  where  the  SE 
praetitioners  eoordinate  their  work  aeross  multiple  systems  is 
unique  in  our  experienee,  and  requires  a  fundamentally 
different  understanding  of  systems  engineering. 

B.  Systems  Engineering  as  a  Service 

Systems  engineering  has  struggled  with  aeeeptanee  in 
rapid-response  environments,  partly  beeause  it  tends  to 
operate  with  a  broader  seope  and  with  the  assumption  that  a 
holistie  view  requires  a  deeper  and  fuller  level  of  knowledge 
than  is  often  available  in  the  rapid  response  time  frame.  In 
rapid  response  environments,  the  time  seale  eonstrains  the 
projeet  seope,  and  detailed  analysis  up  front  is  pereeived  as 
less  aehievable. 

Agile  and  lean  assume  holism  eomes  from  a  learning 
proeess  and  is  valuable  even  when  ineomplete.  The  idea  of 
using  a  pull  system  for  systems  engineering  is  an  attempt  to 
merge  the  breadth  of  SE  into  the  rapid  development  rather 
than  lay  it  on  top  of  the  aetivities.  Our  idea  of  a  KSS  for 
systems  engineering  is  shown  in  Figure  3.  We  believe  it  will 
support  better  integration  of  SE  into  the  rapid  response 
software  environment,  better  utilize  searee  systems 
engineering  resourees,  and  improve  the  overall  system-wide 
performanee  through  a  shared,  more  holistie  resouree 
alloeation  eomponent. 


Figure  3.  Kanban  Scheduling  System  Hierarchy 


In  general,  systems  engineering  is  involved  in  three  kinds 
of  aetivities  in  rapid  response  environments:  Up  front, 
eontinuous,  and  taskable.  Up  front  aetivities  are  eritieal  in 
greenfield  projeets,  but  are  important  in  all  systems  and 
system  of  systems  evolution.  They  inelude  ereating 
operational  eoneepts,  needs  analysis,  and  arehiteetural 
definitions.  Continuous  SE  aetivities  are  ongoing,  system- 
level  aetivities  (e.g.  arehiteeture,  environmental  risk 
management).  These  require  not  only  substantial  time,  but 
also  the  maintenanee  and  evolution  of  long-term,  persistent 
artifaets  that  support  development  aeross  multiple  projeets. 
Taskable  aetivities  are  generally  speeifie  to  individual 
projeets  (e.g.  trade  studies,  interfaee  management),  but  will 
eertainly  draw  on  the  persistent  SE  artifaets  and  knowledge. 

By  viewing  the  development  and  use  of  persistent 
artifaets  as  key  eomponents  of  serviees  provided  to  various 
projeets,  SE  ean  be  opportunistie  in  applying  its  eross-projeet 
view  and  understanding  of  the  larger  environment  to  speeifie 


projeets  individually  or  in  groups.  It  ean  also  broker 
information  between  individual  projeets  where  there  may  be 
eontraetual  or  aeeess  barriers.  When  a  system- wide  issue  or 
external  ehange  oeeurs,  SE  ean  negotiate  or  unilaterally  add 
or  modify  tasks  within  affeeted  projeets  to  ensure  that  the 
broader  issue  is  handled  in  an  effeetive  and  eompatible  way. 
This  is  reminiseent  of  the  agile  management  layer  deseribed 
in  the  iteration  management  approaeh  in  [13],  and  the 
approaeh  envisioned  ean  extend  that  eoneept  throughout  the 
rapid  response  lifeeyele  and  aeross  the  multiple  projeets. 

SE  performs  its  serviees  in  parallel  to  those  aetivities  in 
the  requesting  projeet  and  then  pushes  the  results  to  the 
requestor  as  soon  as  available.  This  is  aimed  at  supporting 
the  timeliness  of  projeets,  so  that  work  ean  eontinue,  even  if 
at  a  higher  risk  of  rework,  unless  waiting  for  the  results  is 
bloeking  all  other  work  in  the  projeet  (not  a  good  thing). 
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Figure  4.  Overview  of  SE  as  a  Service  concept 


SE  serviees  require  persistent  artifaets  and  knowledge  for 
both  requestor-speeifie  and  total  system  artifaets/ 
understanding.  The  quality  of  a  requested  serviee  eould  be 
pre-speeified,  speeified  as  a  parameter  or  input  with  serviee 
request,  or  eould  be  negotiated  as  a  funetion  of  typieal  value 
and  time  available  to  provide  the  serviee.  In  a  KSS,  SE 
serviees  ean  be  thought  of  as  a  single  aetivity.  The  value 
funetion  used  to  seleet  the  next  request  to  be  handled  must  be 
designed  to  identify  the  highest  eost  of  delay  among  the 
queued  requests  in  terms  of  the  overall  system  value.  This 
allows  SE  to  be  a  effeetive  as  possible  in  providing  its 
serviees  aeross  the  enterprise.  The  funetion  eould  be  based 
on  several  parameters  that  are  attributes  of  individual 
projeets,  individual  requests,  or  system- wide  aetivities. 
Possibilities  inelude  the  maturity  of  the  requesting  projeet, 
lifeeyele  point  of  requesting  projeet,  eritieality  of  the 
requesting  projeet,  and  value/eost  of  delay/priority/elass  of 
serviee  or  other  eharaeteristies  of  the  work  impaeted  by  the 
serviee  requested.  The  details  will  be  eritieal  to  aehieve 
system  wide  benefits  without  impaeting  individual  projeet 
timeliness.  Only  through  modeling  is  the  impaet  of  various 
approaehes  to  the  value  funetion  determinable.  In  faet, 
modeling  should  be  able  to  help  identify  the  sweet  spot  of 
the  amount  and  type  of  SE  aetivity  that  produees  the  most 
value  with  the  lowest  impaet  to  quality.  Statistieal  and  other 
measures  will  be  needed  to  traek  the  performanee  and 
improve  the  value  funetion  in  vivo. 


Table  1  describes  categories  of  services.  A  number  of 
services  can  be  defined  in  each  category,  and  if  needed,  such 
definitions  will  be  part  of  follow  on  research  as  the  models 
are  evolved.  It  should  be  noted,  however,  that  developing  the 
concept  of  SE  services  is  outside  the  scope  of  the  currently 
funded  work.  The  actual  definitions  of  services  will  depend 
on  the  context  of  the  projects  and  the  development 
organizations.  In  our  simulations,  we  have  used  the  more 
general  value  of  work  effort  rather  than  detailing  specific 
task  subject  matter. 


TABLE  I.  Systems  engineering  service  categories 


Category 

Description 

Usage 

Translating  Capability 
Objectives 

Proxy  for  customer;  support  for 
requirements  management 
activities 

Continuous; 

Taskable 

Understanding 

Systems  and 
Relationships 

View  across  multiple  projects; 
Persistent  memory  across  time 
and  teams 

Continuous; 

Taskable 

Assessing 

Performance  Against 
Capability  Objectives 

Validation  of  TPMs  or  other 
performance  requirements; 
typical  V&V  type  activities 

Continuous; 

Taskable 

Developing  and 
Evolving  Architecture 

Providing  design  guidance  and 
supporting  common  architectural 
patterns  across  multiple  projects 

Continuous; 

Taskable 

Monitoring  and 
Assessing  Changes 

Supporting  flexibility  and  agility 
by  providing  surveillance  of  the 
external  environment  and 
identifying  issues  and  changes 
that  might  affect  projects 

Continuous; 

Taskable 

Trade  Studies  And 
Decision  Support 

Supporting  system-informed 
decision  making  by  providing 
independent,  competent 
analytical  services  to  the  projects 

Taskable 

IV.  Expected  Benefits 

A  workshop  was  held  at  the  Stevens  Institute  offices  in 
Washington,  DC  on  January  27-28  2010  to  discuss  the 
development  of  a  3 -year  roadmap  for  transforming  systems 
engineering.  The  meeting  identified  issues  currently 
observed  in  instances  of  the  rapid-response  environment 
addressed  in  this  paper.  We  believe,  and  are  working  to 
show,  that  the  following  benefits  are  reasonable  to  expect 
from  the  approach,  and  that  they  address  a  number  of  the 
issues  that  were  discussed  in  that  meeting. 

A.  More  effective  integration  and  use  of  scarce  systems 
engineering  resources 

Using  a  KSS  and  applying  a  model  of  SE  based  on 
continuous  activities  and  taskable  services  is  a  value-based 
way  to  prioritize  the  use  of  scarce  SE  resources  across 
multiple  projects.  The  value  function  within  the  next-work 
selection  process  can  be  tailored  to  provide  efficient  and 
effective  scheduling  that  maximizes  the  value  provided  by 
the  resource  based  on  multiple,  system-wide  parameters. 


Additionally,  having  service  requests  including  time  vs. 
value  parameters  can  help  determine  if  the  delay  of  other 
service  requests  fulfillment  is  warranted  by  the  current 
service  request.  This  is  addressed  further  under  the  value 
function  discussion. 

B.  Flexibility  and  predictability 

SE  activities  are  generally  designed  for  pre-specifiable, 
deterministic  (complete  and  traceable)  requirements  and 
schedules.  There  is  often  an  overdependence  on  unnecessary 
formal  ceremony  and  fairly  rigid  schedules.  Using  cadence 
rather  than  schedule  can  provide  efficient  SE  flow  with 
minimal  planning.  We  believe  that  the  CoS  concept  not  only 
handles  expedite  and  date-certain  conditions,  but  also 
supports  cross-kanban  synchronization.  Even  though  the 
planning  is  dynamic  and  the  selection  of  the  next  piece  of 
work  to  do  asynchronous,  we  believe  the  use  of  a  value- 
based  selection  function,  a  time-cognizant  service  request, 
customized  Classes  of  Service,  and  a  statistically  controlled 
cadence  provide  a  sufficient  level  of  predictability  where 
necessary. 

C.  Visibility  and  coordination  across  multiple  projects 

In  highly  concurrent  engineering  tasks,  the  KSS  provides 
a  means  of  synchronizing  activities  across  mutually 
dependent  teams  by  coordinating  their  activities  through 
changing  value  functions  (task  priority)  according  to  the 
degree  of  data  completeness  and  maturity  (risk  of  change).  It 
also  provides  an  excellent  way  to  show  where  tasks  are  and 
the  status  of  work-in-progress  and  queued  or  blocked  work. 

D.  Low  governance  overhead 

Implementing  a  KSS  doesn’t  require  major  changes  in 
the  way  work  is  accomplished  or  imply  specific 
organizational  structures  like  other  agile  methods  (e.g. 
Scrum).  Such  systems  can  be  set  up  in  individual  projects 
and  allowed  to  evolve  into  more  effective  governance  over 
time  as  the  project  and  the  organization  as  a  whole 
understand  the  best  way  to  attain  value  from  the  practices. 
Even  the  systems  engineering  resource  scheduling  can  be 
implemented  with  very  little  organizational  impact. 
Practitioners  make  most  decisions  using  parameters  set  by 
management  (e.g.  WIP  limits)  and  their  own  understanding 
of  the  needs.  Issues  are  usually  identifiable  from  walking  the 
visible  representation  of  the  flow  status  and  so  are  made 
clear  to  all  who  take  part  in  the  scheduling,  including 
management.  Metrics  are  inherent  to  the  system,  clearly 
identify  problems,  and  track  improvements.  Most  problems 
tend  to  be  self-correcting. 

E.  Increased  project  and  system  value  delivered  earlier 

The  core  rationale  of  most  lean  and  agile  approaches  is  to 
provide  value  to  the  customer  as  quickly  as  possible.  In  rapid 
development  environments  this  is  particularly  important.  By 
limiting  WIP,  more  closely  integrating  the  SE  and  project 
engineering  activities,  and  providing  both  specific  project 
and  system-wide  task  value  determination,  the  KSS  provides 
an  intentional  approach  to  achieving  early  value. 


V.  Future  work 

This  paper  has  described  the  development  of  a  new 
approach  to  managing  systems  engineering  in  an 
environment  where  rapid  response  software  development 
projects  incrementally  evolve  capabilities  of  existing  systems 
and/or  systems  of  systems. 

A  second  part  of  our  research  is  the  modeling  and 
simulation  of  this  approach  to  determine  whether  it 
represents  a  more  effective  way  than  traditional  scheduling 
and  management  paradigms.  Those  efforts  are  described  in  a 
separate  paper  [19]. 

We  have  concurrently  iterated  the  concept,  the  models, 
and  the  simulations,  hoping  to  determine  if  the  approach 
modeled  in  vitro  is  sufficiently  likely  to  provide  the 
hypothesized  benefits  in  an  in  vivo  implementation.  Using 
the  work  so  far,  we  will  gather  additional  baseline  data  to 
refine  and  calibrate  the  models  and  simulations,  and  are 
already  discussing  instrumented  pilots  of  the  approach  with  a 
number  of  companies  in  the  US. 

We  are  also  looking  to  improve  the  model  of  the  SE 
services  to  include  negotiation  and  the  other  human/social 
aspects  of  the  processes.  We  believe  this  is  particularly 
important  in  solving  issues  around  implementing  more 
closely  coupled  systems,  software,  and  stakeholder 
development  collaborations. 
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